      *      *                   *     *                          *
      **     *                   **   **                          *
      * *    *             *     * * * *          *          *    *
      *  *   *   *****  *******  *  *  *   *****  ******  ******* ******
      *   *  *  *     *    *     *     *  *     * *     *    *    *     *
      *    * *  *******    *     *     *  *     * *     *    *    *     *
      *     **  *          *     *     *  *     * *     *    *    *     *
      *      *   ******    *     *     *   *****  *     *    *    *     *
      *                                                                 *
      *         The monthly guide to BITNET servers and services        *
      *                                                                 *
      *  Volume 1  Number 8                              February 1987  *
      *                                                                 *
       *****************************************************************
      *                                                                 *
      *  Editor:                          Chris Condon  CONDON@YALEVMX  *
      *  Assistant Editor:                Steve Sutter  SUTTER@YALEVMX  *
      *  NetMonth Staff Supervisor:       Gary Moss       MOSS@YALEVMX  *
      *                                                                 *
       *****************************************************************
      *                                                                 *
      *                                                                 *
     RRRRRRRR    EEEEEEEEE      AAA      DDDDDDD     EEEEEEEEE   RRRRRRRR
     RRRRRRRRR   EEEEEEEEE     AA AA     DDDDDDDD    EEEEEEEEE   RRRRRRRRR
     RR     RR   EE           AA   AA    DD    DD    EE          RR     RR
     RR     RR   EE          AA     AA   DD     DD   EE          RR     RR
     RRRRRRRR    EEEEEEE     AA     AA   DD     DD   EEEEEEE     RRRRRRRR
     RRRRRR      EE          AAAAAAAAA   DD     DD   EE          RRRRRR
     RR   RR     EE          AA     AA   DD    DD    EE          RR   RR
     RR    RR    EEEEEEEEE   AA     AA   DDDDDDDD    EEEEEEEEE   RR    RR
     RR     RR   EEEEEEEEE   AA     AA   DDDDDDD     EEEEEEEEE   RR     RR
      *                                                                 *
      SSSSSSS    UU     UU   RRRRRRRR    VV     VV   EEEEEEEEE   YY     YY
     SSSSSSSSS   UU     UU   RRRRRRRRR   VV     VV   EEEEEEEEE   YY     YY
     SS     SS   UU     UU   RR     RR   VV     VV   EE           YY   YY
     SS          UU     UU   RR     RR   VV     VV   EE            YY YY*
      SSSSSSS    UU     UU   RRRRRRRR    VV     VV   EEEEEEE        YYY *
      *     SS   UU     UU   RRRRRR       VV   VV    EE             YYY *
     SS     SS   UU     UU   RR   RR       VV VV     EE             YYY *
     SSSSSSSSS   UUUUUUUUU   RR    RR       VVV      EEEEEEEEE      YYY *
      SSSSSSS     UUUUUUU    RR     RR       V       EEEEEEEEE      YYY *
      *                                                                 *
      *    IIIIIIIII    SSSSSSS     SSSSSSS    UU     UU   EEEEEEEEE    *
      *    IIIIIIIII   SSSSSSSSS   SSSSSSSSS   UU     UU   EEEEEEEEE    *
      *       III      SS     SS   SS     SS   UU     UU   EE           *
      *       III      SS          SS          UU     UU   EE           *
      *       III       SSSSSSS     SSSSSSS    UU     UU   EEEEEEE      *
      *       III             SS          SS   UU     UU   EE           *
      *       III      SS     SS   SS     SS   UU     UU   EE           *
      *    IIIIIIIII   SSSSSSSSS   SSSSSSSSS   UUUUUUUUU   EEEEEEEEE    *
      *    IIIIIIIII    SSSSSSS     SSSSSSS     UUUUUUU    EEEEEEEEE    *
      *                                                                 *
      *                                                                 *
       *****************************************************************

1

   ************************************************************************
  * Contents                                                               *
  **************************************************************************

  Bitnotes ............................................................... 1
  The NetMonth Reader Survey ............................................. 2
  The Simtel20 Archives .................................................. 6
  Listserv's File Server Functions ...................................... 10
  Odd Parity ............................................................ 15
  The Ethics of Computer Conferencing ................................... 16
  Electronic Chain Letters .............................................. 17
  New Mailing Lists ..................................................... 18
  The CSNET Information Server .......................................... 19
  The United States Data Defense Network - Network Information Server ... 21
  The Color and Vision Network .......................................... 22
  Feedback .............................................................. 23
  Policies .............................................................. 26

  NetMonth is a  network service  publication  distributed free of charge to
  students and professionals in BITNET and other networks. This magazine and
  it's companion  file, BITNET SERVERS, are  the work  of the  Yale Computer
  Center BITNET  Services  Library  (BITLIB) staff.  The  BITLIB  is a local
  online help facility designed to  inform  Yale network  users  about  what
  services are available to them  through BITNET, and  provide  instructions
  and  utilities  for their  proper use.  In publishing NetMonth  the BITLIB
  staff  members hope  to share the  fruits of their labor with institutions
  outside of Yale in  order to promote a productive and enjoyable networking
  environment for everyone.

  BITNET SERVERS is BITNET's most  complete  and up-to-date  list of servers
  and services.  It is sent to  NetMonth subscribers at the same time as the
  magazine.  BITNET SERVERS is dependent on your support to remain accurate.
  If you know of servers and services  not  listed  in BITNET SERVERS, or of
  those listed in the file that are no longer available, please  contact the
  NetMonth staff at BITLIB@YALEVMX.

  Subscribing to NetMonth and BITNET SERVERS:  Send a mail message with your
  name and  network  address (userid@node) to  BITLIB@YALEVMX (Arpanet users
  send  your mail to BITLIB%YALEVMX.BITNET@WISCVM.WISC.EDU).  A subscription
  to NetMonth is also brings you BITNET SERVERS.  You do not need to request
  both.  In  order  that  we may  maintain the most  efficient  mailing list
  possible we ask that you inform us prior to the expiration of your userid.

  Article  submissions  and  Letters  to the  Editor  are both  accepted and
  encouraged.  See  the "NetMonth Policies"  section  at  the  end  of  this
  magazine for more information.

  Printing this file:  VM users may print this  file  by  first  copying  or
  renaming the file to NETMONTH LISTING and then printing the resulting file
  using your local file printing command.  In this way page breaks and other
  formatting will be recognized by your printer.

  --------------------------------------------------------------------------

  FuzzyBytes Electronic Publishing                     "Because We're Here."

1

                                                                       Page 1


   *************************************************************************
  * Bitnotes                                                        Issue 7 *
  ***************************************************************************

  Well, let me say this about that...

  A small celebration is in order.  The NetMonth/BITNET SERVERS  mailing list
  has  reached  (actually, exceeded)  the  500-subscriber milestone.  This is
  a significant number, not only because it  is so  large,  but because there
  are  now twice  as many  readers  as  there  were  when the  first issue of
  NetMonth hit the newstands only  eight months ago.   The reaction  from the
  staff ranged from astonishment to extreme glee.

  The general consensus:  "It looks like we're doing something right."

  The letters and comments in the  subscription requests seem to support this
  opinion.  I certainly have no objection to people  saying nice things about
  the staff, the magazine, or my taste in cover art.  (On the  contrary, I am
  known to thrive on that sort of thing). Some of you will remember, however,
  that I feel terribly cheated when I  receive little creative input from the
  readers.  How could the magazine be  better?  What  would  you like to see?
  Are we doing  anything that  annoys you?  What  should  we emphasize?  What
  aren't we emphasizing enough?

  Yes, it is time once again for a Reader Survey. Those of you who are on the
  mailing list for NetMonth will be  receiving the file NETMONTH SURVEY along
  with BITNET SERVERS and this issue.  This should make it terribly  easy for
  you to  answer  the  questions by  editing the file.   The completed survey
  should be sent  to BITLIB@YALEVMX (by mail is possible).   For those of you
  who are  not on the  mailing  list for NetMonth, the survey appears in this
  issue.

  The directions this  magazine  takes in  the future  are directly dependant
  upon  your  answers.  Most  of the  questions  on  the survey  are multiple
  choice, but the most important questions are  those where  you are asked to
  give your opinion.  There are also a number of questions about which BITNET
  servers and services you use most often.


  Blurring identities...

  A file server is a file server, unless of course, it is also a name server.
  Then it is niether, or both.  Many of  our file  servers  have taken on the
  duties of name  servers, notably NETSERV.  The  name "file server"  doesn't
  exactly do it justice, and "name server" doesn't  even  come close. Somehow
  we get by and list it separately under both categories.  This sort of thing
  is so commonplace that we don't even notice anything odd about it.

1

                                                                       Page 2


  A list server is a list server, unless of course, it is also a file server.
  Then it is... strange.  Yes,  LISTSERV  now runs  as a file server,  with a
  command  set  that  you couldn't  tell from  NETSERV's  unless  you  looked
  closely.  This added  utility will allow members of mailing lists to easily
  access list  archives.  List maintainers will be able to make various files
  available to  subscribers.  Everybody  will  be  happy.  See the article on
  Listserv's file server functions in this issue.

  Thanks where thanks is due...

  Thanks to those people who contributed  articles  for this  month's  issue:
  John R. Cook sent in some  suprising  results from his Relay Ethics survey.
  (Well, they suprised  ME, anyway.)  Eric Thomas contributed the information
  on Listserv's file server functions, and Peter Kaiser wrote about the Color
  and Vision  Network.  Finally, thanks to Steve Middlebrook for informing me
  about the  SIMTEL20 ARCHIVE-REQUEST and how I could get instructions on how
  to use it.

                      Virtually,

                          Chris Condon@YaleVMX


   *************************************************************************
  * The NetMonth Reader Survey                                              *
  ***************************************************************************

  Please return your survey responses to BITLIB@YALEVMX via mail if possible.
  All answers will be kept confidential.  Thank you for your time...


   *************************
  * Part One - Who are you? *
  ***************************


  Answer
  column

  +----+
  ]    ]  1.  How long have you been reading NetMonth?
  +----+
              a. 1-2 months
              b. 3-4 months
              d. 5-8 months
              e. I was a Bitlist reader

1

                                                                       Page 3


  +----+
  ]    ]  2.  Are you a(n):
  +----+
              a. undergraduate student >>>Please specify major:
              b. graduate student >>>Please specify degree:
              c. computer center staff >>>Please specify:
              d. educator (doctor, professor, teacher, etc.)
              e. other >>>Please specify:

  +----+
  ]    ]  3.  How old are you?
  +----+
              a. 18-25
              b. 26-35
              c. 36-50
              d. 51+
              e. none of your business!

  +----+
  ]    ]  4.  Are you:
  +----+
              a. male
              b. female

  +----+
  ]    ]  5.  Do you read any electronic magazines other than NetMonth?
  +----+
              a. yes
              b. no

              If "yes", which ones:

              +-------------------------------------------------------------+
              ]                                                             ]
              ]                                                             ]
              ]                                                             ]
              +-------------------------------------------------------------+

  +----+
  ]    ]  6.  Do you subscribe to any digests/mailing lists?
  +----+
              a. yes
              b. no

              If "yes", which ones:

              +-------------------------------------------------------------+
              ]                                                             ]
              ]                                                             ]
              ]                                                             ]
              ]                                                             ]
              +-------------------------------------------------------------+

1

                                                                       Page 4


  +----+
  ]    ]  7.  How often do you sign on to RELAY?
  +----+
              a. almost every day
              b. a few times a week
              c. a few times a month
              d. not more than once a month
              e. never

  +----+
  ]    ]  8.  Have you ever used a file server before?
  +----+
              a. yes
              b. no

              If "yes", which three do you use most often?

              +-------------------------------------------------------------+
              ]                                                             ]
              ]                                                             ]
              ]                                                             ]
              ]                                                             ]
              +-------------------------------------------------------------+

  +----+
  ]    ]  9.  Have you registered yourself on a name server (for example, the
  +----+      NETSERV User Database or the CSNEWS Bitnauts List)?

              a. yes
              b. no

              If "yes", which ones?

              +-------------------------------------------------------------+
              ]                                                             ]
              ]                                                             ]
              ]                                                             ]
              ]                                                             ]
              ]                                                             ]
              +-------------------------------------------------------------+

  10.  What operating system is your mainframe running?

              +-------------------------------------------------------------+
              ]                                                             ]
              +-------------------------------------------------------------+

1

                                                                       Page 5


   *********************
  * Part two - NetMonth *
  ***********************


  11.  What do you feel are NetMonth's strong points?  (Use more space if you
       need it.)

       +--------------------------------------------------------------------+
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       +--------------------------------------------------------------------+

  12.  What do you feel are  NetMonth's weak  points?  (Use more space if you
       need it.)

       +--------------------------------------------------------------------+
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       +--------------------------------------------------------------------+

  13.  In what ways do you feel NetMonth could be improved?  (Use  more space
       if you need it.)

       +--------------------------------------------------------------------+
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       +--------------------------------------------------------------------+

  14.  What would you like to see in future issues? What kind of ideas do you
       have?  (Use  more space if you need it.)

       +--------------------------------------------------------------------+
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       +--------------------------------------------------------------------+

1

                                                                       Page 6


  +----+
  ]    ]  15. The best issue of NetMonth so far was:
  +----+
              a. July 1986
              b. August 1986
              c. September 1986
              d. October 1986
              e. November 1986
              f. December 1986 - January 1987
              g. February 1987
              h. No opinion

              Why?

              +-------------------------------------------------------------+
              ]                                                             ]
              ]                                                             ]
              ]                                                             ]
              ]                                                             ]
              +-------------------------------------------------------------+


  16.  What stand  out in  your mind  as the  best and  worst things you ever
       read in NetMonth?

       +--------------------------------------------------------------------+
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       ]                                                                    ]
       +--------------------------------------------------------------------+


   *************************************************************************
  * The SIMTEL20 Archives                                                   *
  ***************************************************************************

  There is a collossal  amount of  free public  domain software for the CP/M,
  PCDOS/MSDOS  and   UNIX  operating  systems,   and  for  the  DoD  standard
  programming   language,  Ada,  in  several  archives  on  SIMTEL20.ARPA,  a
  DECsystem-20  running  the TOPS-20  operating system at White Sands Missile
  Range.

  To obtain a  directory  listing of  interest to you,  send your  request to
  ARCHIVE-REQUEST@SIMTEL20.ARPA  with up  to five of  the following  commands
  in the body of any one message:

  SEND PD:CPM.CRCLST
  SEND PD:CPMUG.CRCLST

1

                                                                       Page 7


  SEND PD:SIGM.CRCLST
  SEND PD:PC-BLUE.CRCLST
  SEND PD:MSDOS.CRCLST
  SEND PD:UNIX.CRCLST
  SEND PD:ADA.CRCLST
  SEND PD:MISC.CRCLST

  The PD:  archive  is  the  one  to watch  for  the  very  latest  CP/M
  offerings, as  it is  updated  frequently.  The PD:,  PD:  and
  PD: archives contain software distributed by the CP/M Users Group,
  the  SIG/M  Users  Group and  the  PC-Blue Users Group  respectively.  This
  software  is available  on diskettes  from the associated users groups, and
  the archives are updated as new volumes are issued.

  The  PD: archive  contains  software  for  the  IBM-PC and similar
  machines.   Some   runs  under   CP/M,  and  some  under  PCDOS/MSDOS.  The
  PD: archive also contains software for the MSDOS and PCDOS operating
  systems; but this archive is locally managed, and therefore is updated more
  frequently than the PD: archive.

  The  PD: archive contains a variety of UNIX tools.  Those which apply
  specifically to CP/M are in the directory PD:.

  The PD: archive is growing rapidly.  Information about this archive is
  in directory PD:.

  In general, the archived software is very good, having been worked-over and
  refined by many users.  The documentation and comments tend  to be complete
  and informative.  Files in all of these archives  can be obtained using the
  ARCHIVE-REQUEST procedures described in this article.

   ************
  * Disclaimer *
  **************

  Please  note that  due to the  large number of files available, the archive
  maintainers cannot possibly attempt to validate the proper operation of the
  various programs. When a program bug is reported, immediate action is taken
  to either  correct  the error  or remove  the  offending  program  from the
  archives.  Still,  users must  understand  that all  archive  programs  are
  offered  AS-IS,  and the  archive  maintainers  specifically  disclaim  any
  liability should these programs  malfunction or cause damage, incidental or
  otherwise.  When testing  ANY new software, be certain that all information
  stored on disk is backed-up  before  you start,  so that you can recover if
  files are damaged  or erased.  This is particularly true if you have a hard
  disk, in which case malfunctions can be spectacularly disasterous.

1

                                                                       Page 8


   ****************************
  * How to use ARCHIVE-REQUEST *
  ******************************

  To obtain up  to five files in a single request message by netmail from the
  public domain  archives kept on SIMTEL20.ARPA, send a message to:

  ARCHIVE-REQUEST@SIMTEL20.ARPA

  The  message  body must contain  lines beginning with the keyword SEND, one
  SEND line for each file requested.  Case is  not significant.  The  general
  syntax of a SEND line is:

  SEND format filename

  In general, a filename consists of the following components:

  device:file.type.generation

  "device:" is usually PD:, and the combination of PD: is expected
  unless an  alias has been  advertised of the form "alias:", which takes the
  place of both device and directory fields.  The  generation field should be
  left off in order to default to the highest generation number so you can be
  sure of  getting the  latest  version  of the  file requested.  "file.type"
  follows the usual filenaming conventions.

  In all formats listed below, if the file to be sent is larger than 55K, the
  file is sent in numbered parts.  The parts must be reassembled in order and
  edited to remove any headers, preface, and  trailers before the process can
  be reversed to reconstruct the original file.

  Allowable formats are:

  SEND HELP
        Much like what you are reading now.

  SEND INFO
        A detailed description of the SIMTEL20 Archives, which  includes this
        file, pointers to certain key files, and descriptions of various file
        transfer programs and related utilities.

  SEND BOOTSTRAP
        A  brief  quick  reference  listing of filenames of the key utilities
        used  to  reconstruct  files  sent  by the  compression and  encoding
        techniques listed below.

1

                                                                       Page 9


  SEND DIR filespec
        This  format  returns a  CRC list  of the requested files, and is the
        only  format  which  allows  wildcard  filenames  (but  not  wildcard
        directory names).  The  list  is sent  as an  ASCII  text  file.  The
        wildcard characters are "*" and "%".  The asterisk  means  any number
        of characters, while the percent  sign means  exactly  one character.
        Either or both may  appear in any  combination  in either or both the
        file  or type  fields, while  only the  asterisk  may  appear in  the
        generation field.

  SEND RAW filename
        If the file is ASCII, it  is sent  as-is,  regardless  of size.  This
        format  is  the  least  efficient   over  network  and  mail  gateway
        resources.  Use this format only if you absolutely must.

  With the  four formats  listed below,  if the file  is ASCII  and under 25k
  characters, it is sent as-is, as if RAW format was requested.  Binary files
  are always processed according to the requested format.  However, a request
  for ARC  or SQ  processing of  files with type ".ARC", ".LBR", or ".%Q%" is
  ignored  and  the  original  file  is  either  uuencoded  or  hexified  (if
  possible), according to the requested format. If the file was not sent RAW,
  a short  preface is  inserted  at the  front  of the message describing the
  process actually taken and a CRC entry describing the original file.

  SEND ARE filename  or  SEND filename
        The original file is made into a uuencoded ARC file.

  SEND ARH filename
        The original file is made into a hexified ARC file if the ARC file is
        under 64K bytes long.  Otherwise,  an apology  is returned instead of
        the requested file.

  SEND SQE filename
        The original file is made into a uuencoded SQueezed file.

  SEND SQH filename
        The  original  file  is  made  into  a hexified  SQueezed file if the
        Squeezed  file  is under  64K  bytes  long.  Otherwise, an apology is
        returned instead of the requested file.




                                   * * *
                                * * * * * *
                                   * * *

1

                                                                      Page 10


   *************************************************************************
  * LISTSERV's File Server Functions                                        *
  ***************************************************************************

  by Eric Thomas                                               ERIC @ FRECP11


   **************
  * Introduction *
  ****************

  Although the primary  function of LISTSERV is to  distribute mail and files
  to  pre-defined  distribution  lists,  it may  often be  desired to provide
  the subscribers  of the  list  with a  set  or  data or program files to be
  periodically  maintained  by a  particular  person or set of persons. Apart
  from the  obvious  example  of list  "notebooks" (archives), working groups
  might want to provide minutes  of  internal  meetings  held by  some of the
  subscribers, technical groups  might  want to  share  application  programs
  and/or mods to a program they are all using, etc.

  It  was  decided  that the  more  convenient  way of  meeting  these  needs
  was to provide basic,  non-specialized file-server functions along with the
  mail-processing  functions  of  LISTSERV.  Those  functions  would  have to
  provide  powerful  yet  list-based  file  access  control  and  remote file
  updating  facilities,  under  the  control  of both the list  owner and the
  LISTSERV   management.  Automatic  distribution   of  updated  material  to
  subscribers  was  another  major  goal  since  it  makes  this distribution
  more efficient  whenever  several  peers are  created  to  support the list
  and relieves the file maintainer  of the  burden  of  preparing the list of
  subscribers -- it is the users  that  request  such  distribution  from the
  server without any intervention from the file maintainer.

  It  was   decided  that  LISTSERV  should  conform  to the well-implemented
  and  well-accepted   standard  command   set  of  the  Netserv  file-server
  developed  by Berthold Pasch  (PASCH@DHDIBM1) for EARN.  Commands should be
  similar  enough  not  to   confuse  unexperienced  users  who  switch  from
  one of the servers to the  other,  with  additional  commands or parameters
  being provided  if  needed.  All the  commands  would not  be  supported of
  course. The  LISTSERV  commands  should  conform  to  the  general LISTSERV
  convention  whenever  there  is a  conflict  between LISTSERV  and  NETSERV
  conventions, the best solution being  of course to support both conventions
  to  allow  for application  programs  written for  NETSERV  to operate with
  LISTSERV with a minimal amount of changes.

  A  presentation  of  the  set  of commands  that were retained will follow.
  You  should  note that  a significant  number  of these  commands  have the
  same  syntax   for  LISTSERV and  NETSERV and yet  operate very differently
  on  the two servers (the best example being the PW command).

1

                                                                      Page 11


   ***********
  * FILELISTs *
  *************

  Several "file  directories"  (FILELISTs)  were required to  allow each list
  to have  its  own set of files, independently  from each other, and to make
  it possible  to hide  the very existence  of those  files from those  users
  who  are not supposed to retrieve  them.  LISTSERV  maintains  a  number of
  FILELISTs which can be  nested in each other if needed. The "root" filelist
  is  called  LISTSERV FILELIST  and is  always  maintained  by  the LISTSERV
  management. In  UNIX terms, a  FILELIST is  a "directory" which can contain
  sub-directories (any level of nesting is allowed) and  is  defined  upwards
  in the tree structure with the  root being LISTSERV FILELIST.

  To review the contents of a filelist, you can either request it to be  sent
  to you by means of the  usual "GET" command (see below) or use the  special
  command "INDEX":

  INDex                 

  Sends  you the  specified  filelist   (defaults to LISTSERV FILELIST). This
  command is  strictly  equivalent  to   "GET filelist_name FILELIST" and has
  been made  available for  compatibility  with  other  file  servers  on the
  network.

  LISTSERV  filelists  are  nearly  fully  compatible  with  the ones you may
  obtain from  Netserv.   The header  of the  filelist  will give information
  about the  contents  of  the  filelist  and a  list  of  File  Access Codes
  (FACs) which will be  used  later  in the body of the filelist and identify
  who will be  able  to  retrieve  or  store the file  in  the  server.  This
  FAC list is included between  "banners" made  of an  asterisk,  a blank and
  a full  line  of  colons,  and  will  usually  have  been commented  by the
  maintainer  of  the  filelist  to  help  you  understand  to whom  the FACs
  refer.

  The  body  of  the  filelist  will   contain  file  declaration,   possibly
  interspersed  with  comment  lines.  Comment  lines start  with an asterisk
  in column one.  The format of the other lines is as follows (column numbers
  are given for easier reference by application programmers):


  1 3       12         23  26  31  35    41    47       56       65
  ] ]        ]          ]   ]   ]   ]     ]     ]        ]        ]
  V V        V          V   V   V   V     V     V        V        V
    filename filetype   get put rfm lrecl nrecs date     time     description
    SAMPLE   FILE       ALL CTL VP    106    85 86/11/12 19:50:14 Dummy file


  filename       is the 'name' of the file to be used in the "GET" command.
  filetype       is the 'type' of the file to be used in the "GET" command.

1

                                                                      Page 12


  get            is the FAC  that controls read access to the  file. That is,
                 people who do not "meet" that  FAC will not be able to issue
                 GET commands for the file.

  put            if the FAC  that controls write access to  the file. Usually
                 points to the file maintainers.

  rfm            is the record-format of the file. The first letter is either
                 "V" for "Variable length" or "F" for "Fixed length records",
                 while  the second  letter will  be  set to  "P" for  "Packed
                 format  files" or  left blank  for normal  files. Note  that
                 packed files  will be automatically unpacked  prior to being
                 sent to you as a result of a GET or Automatic File Distribu-
                 tion command;  however if  you obtain a  direct link  to the
                 disk on which  they are stored, you will find  them to be in
                 packed format.

  nrecs          is the  number of  records in the  file. Files  flagged with
                 nrecs = 0 and dots in the other fields are not yet available
                 but can be subscribed to or stored by their maintainer.

  date/time      is the  date the file  was last updated, in  yy/mm/dd format
                 (this makes  it easier to  sort the filelist by  date). Note
                 that the process of updating  the "date" field in a filelist
                 causes this filelist to be flagged as changed and the corres
                 ponding date/time in  its entry up the tree  structure to be
                 modified accordingly.


   ********************
  * Ordering the files *
  **********************

  GET       fn ft       

  Sends you  the requested file  provided you are authorized  to retrieve it.

  Synonyms have been defined for the GETND, GETDD, GETPP  and GET80  commands
  of Netserv.  "GETND xxxx" is translated to  "GET xxxx F=Netdata", etc. Note
  that in  this implementation, GETPP  and GET80 are strictly equivalents and
  will cause the file to be  sent in  Listserv-Punch  format  if  its logical
  record length is greater than 80. Send an "Info LPUNch" command to LISTSERV
  for more information  about Listserv-Punch format.

  You can use the GET command, or its synonym SENDME, to request a file to be
  sent  to you. You must  specify the filename and  filetype  of the  file as
  their  appear  in  the  filelist,  and  you  may  optionally append a third
  parameter  to the  command  to indicate  from  which  filelist you want the
  search  for  the  file to start.  This  parameter is  normally not required

1

                                                                      Page 13


  unless there is  more  than  one file  available  from  LISTSERV  with  the
  "filename  filetype"  you  are  requesting.  Application programs who issue
  GET  commands to  LISTSERV and know the filelist  name  should  specify  it
  since it  speeds  up  the  filelist search.  The default is to start at the
  root filelist, of course.

  The LISTSERV-standard "file-format"  keyword ("F=fformat") is supported  on
  this  command. Additionally, synonyms have been  defined  for  the  Netserv
  GETxx  commands. Note  that the Netserv  "GET80" format is not supported by
  LISTSERV; LISTSERV-punch format is substituted.

  The  LISTSERV  "GET"  command  is  compatible  with  the  NETSERV one, with
  the exception  of  the  GET80  format  restriction  and  with  the addition
  of  the  optional  file-format  keyword  and  filelist_name parameters. The
  "prologtext"  feature  of NETSERV is  not  implemented  in the LISTSERV GET
  command.


   **********
  * Packages *
  ************

  The  term  "package" refers to  a set of  program or data  files which  are
  supposed  to  be retrieved together under  normal conditions. Provision has
  been  made  to  allow  for  users to  retrieve those packages with a single
  command, and to subscribe to  it  as a  whole with updated versions of only
  the  individual   changed  files  being  sent  out.   The  package   exists
  independently  of its individual components  which can still be  referenced
  separately.

  With  each  package  is associated a dummy file and a definition file.  The
  dummy file has a fileid of "packagename PACKAGE" and does not really exist.
  However, ordering this dummy file will cause the  whole  set of files to be
  sent to you. Similarly, subscribing to this single  dummy  file will result
  in a global subscription for all the components  of  the package. The dummy
  file should be used whenever reference is  made to the package as a whole.

  The  definition  file  has  a  fileid  of  "packagename $PACKAGE" and lists
  the  set  of  files  that  are  contained in the package.  Unlike the dummy
  file,  it  really  exists  and  can be retrieved as  any other normal file.
  It  will  usually  list  itself as  first  file of the package  so that you
  can check  you have  received  all the  files in the package after ordering
  it. It may  reference  another  package  which  is required for the package
  to be  used (any level  of  nesting  is  allowed).  If  you subscribe  to a
  package  via  Automatic  File  Distribution (qqv),  you  will automatically
  receive  updated  versions  of all  the corresponding  sub-packages if they
  are  updated.  Similarly, ordering  the  package will cause all subpackages
  to be sent to you alike.

1

                                                                      Page 14


   ***********
  * Notebooks *
  *************

  LISTSERV is able to automatically keep  notebooks for a list if desired  by
  the  list owner.  Those notebooks  are  listed in a special filelist called
  "NOTEBOOK  FILELIST", which  is  automatically  maintained  by  the  server
  according  to  the parameters specified  in  the  headers  of  the  various
  lists. The filelist can be subscribed to via FUI (see LISTAFD MEMO for more
  information) but AFD distribution has been  locked out to avoid  generating
  too much traffic as  this filelist is very likely to be  updated every  day
  and  to be quite  large. It can  be obtained  via the normal GET command.

  The files listed  in the NOTEBOOK filelist are just  like normal files  and
  can  be  retrieved  as indicated  by  the  GET  File  Access Code. They can
  be subscribed to as normal files, and  can  even be  modified or deleted by
  the list  owners,  as indicated  by  the  PUT FAC. However,  once the files
  are deleted  they will disappear  permanently  from  the  filelist  (unlike
  normal files which would be forced to nrecs = 0).


   *********************
  * Other documentation *
  ***********************

  More  information  about  the Automatic  File  Distribution feature  can be
  obtained  from  LISTAFD MEMO  ("Info  AFD").  File owners  should  retrieve
  LISTFOWN MEMO ("Info  FILEOwner") for more information on  the PUT  command
  and internal filelist format.  A complete description of the Listserv-PUNCH
  format  (with sample  PASCAL conversion program)  can be  found in LISTLPUN
  MEMO ("Info LPUNch").

  Information  about  Netserv can  be obtained by retrieving NETSERV HELPFILE
  or NETSERV REFCARD from the nearest Netserv host.




                                      . +                          .
            *      You aren't here     .       +                    .
       .     +            ]        *.         *              +   .
     *      *    .        ]        .    +       .        *  ..
             .      +     V   *             .      .              .
                      .   .     .   .             +   . +
                  .  .                  *                 *
            +                +                      *
                   .                                           .


1

                                                                      Page 15


   *************************************************************************
  * Odd Parity                                                              *
  ***************************************************************************

  Here is  the first of  many monthly columns  by our own  Assistant Ediitor,
  Steve Sutter. We are calling this Odd Parity because, well, it was the only
  title we could think of at the time.  Luckily  the title  works, since this
  is rather odd (and you can figure out the Parity bit for yourself).  We are
  rather lucky to have Steve on our staff,  partly because he is not yet what
  you would call a network guru.   He is, to put it bluntly, a typical BITNET
  user.    How long this  will last,  I don't know.   One  can't work on this
  magazine and not learn something eventually.   In the meantime,  enjoy this
  perspective while you can:                                          - Chris

  by Steve Sutter                                              SUTTER@YALEVMX

  Just recently I was looking over the list of nodes  connected to Bitnet.  I
  hadn't looked at it in about a year,   and was surprised to see how much it
  has grown.   The geographical implications of  the list are impressive.   I
  have tried to come up with a few ideas on how this fact can be used.

  My  first  idea would  be  some  form  of  a file  server  for  information
  concerning travel.   I  imagine that many people end up  traveling to other
  universities quite frequently.   I think it would be very helpful to have a
  file for each  site describing how to  get there,  where the  train and bus
  stations are, what roads to avoid,  and possibly where to stay and eat.   A
  little more  ambitious would  be a  description of  the area.    I find  it
  aggrevating to see a node name and not  have any idea where it is,  or what
  it is like there.    I think this would be especially  interesting for more
  distant nodes,  and would help to "beautify" the net in general.   Although
  it would take some constant effort,  a  list of local events would be nice,
  and while  I'm at it how  about car pooling information.    Incidently,  if
  every site would clean  out a basement somewhere and open it  up as a youth
  hostel sort of thing, reservations could be made over the net.  Well, maybe
  I am getting over-ambitious.

  Another less  practical idea would  be a  newspaper of sorts.    This would
  require a  great deal of  effort,  but it  would be  sort of like  a static
  relay.   It would be nice to see some articles about student life, research
  accomplishments,   and even  local  news of  interest.    If enough  people
  responded, it might be possible to come up with weather predictions!  Well,
  anyway I think it  would make a good magazine,  the  Net Community Gazette.
  Who knows, with enough local input it might even scoop some of the hardcopy
  newspapers.  Maybe it would make a good NetMonth spinoff...

  Finally,  I think the  Net itself would be a good place  to do research,  a
  virtual  laboratory of  sorts.   I  would suggest  maybe a  digest for  the
  posting of surveys.   This would probably have to moderated,  but hopefully
  not too seriously.   I think that if  the results were also posted,  people

1

                                                                      Page 16


  would actually bother to  do some of the surveys,  especially  if they were
  brief.   The  only problem is that  the survey group wouldn't  change much.
  After all,  even  a great magazine like  NetMonth has less than  a thousand
  subscribers.

  Well, I will stop rambling now.   If any of these ideas already exist,  let
  me  know.    If  you  find them  offensive  and/or  stupid,   I  apologize.
  Otherwise, think about it, and I will look for the results.


   *************************************************************************
  * The Ethics of Computer Conferencing                                     *
  ***************************************************************************

  By John R. Cook                                          UD118169 @ NDSUVM1

  The objectives of the present study  were twofold.   First,  an attempt was
  made  to assess  the extent  to  which  some  traditional  moral principles
  governing face-to-face communication have gained acceptance by the users of
  computer conferences.   This was done by assessing the prevailing community
  standards  for computer  conferencing on  Compuserve's CB  and on  BITNET's
  Relay.    The assessment  was carried  out  using email  and other  message
  facilities on both of these networks  to distribute a 24-item questionnaire
  entitled Questionnaire for Users of "CB's" and Other Computer "Chats".  The
  second objective of the study was to  explore some approaches that might be
  taken towards distributing questionnaires and collecting data over computer
  networks.

  The 25  CB and  112 Relay  users  participating  in the  study tended to be
  male,  undergraduate students in their mid-twenties and their average level
  of education was  that of a college  sophomore.   Six of the  CB users also
  turned out to be Relay users.   In terms of their use of electronic journal
  and mail services,  the largest portion of Relay users (21%)  were Psychnet
  subscribers, followed by NetMonth (17%) and COMSERVE (16%).

  CB  users  were  found  to  be  much more  reluctant to participate  in the
  study than Relay users,  as evidenced by their lower response rate.   Also,
  Relay users were  found to be more  accepting of a proposed  rule requiring
  users to register  their true names and identities before  signing onto the
  system.   Otherwise, there was a high degree of similarity in the responses
  of CB and Relay users on this survey.

  The  moral  or  ethical  standards  for  computer conferencing  revealed by
  the survey  were found to be  largely consistent with the  moral principles
  governing face-to-face  communication.   One  difference between  computer-
  mediated and  face-to-face communication  was suggested  by the  conference
  users' greater acceptance of practices such  as adopting nicknames that are
  considered  sexually  provocative  or sharing  details  of  one's  intimate
  personal relationships on  a public channel.   However,  when  CB and Relay

1

                                                                      Page 17


  users  were   asked  to  evaluate   the  potential  benefits   of  computer
  conferencing,  they  appeared to discount the  importance of some  of these
  practices,  in a way that brought them  back in line with traditional moral
  principles governing face-toface communication.

  In  conclusion,  it  seems  we  do  tend  to attach importance to  the same
  sorts of  activities both  on- and  off-line.   In  this respect,   several
  traditional moral principles governing  face-toface communication have been
  found to be accepted by the users of computer conferences.   One area where
  discrepancies  between our  on-and off-line  ethical standards  do tend  to
  occur,  is in the  larger range of behaviors we are  willing to consider as
  morally acceptable in other conference users.


   *************************************************************************
  * Electronic Chain Letters                                                *
  ***************************************************************************

  (Extracted from CSNEWS@MAINE)

  Recently, the  problem of chain  letters being  distributed  by  electronic
  mail facilities  is  increasing,  and  the  number of  complaints  received
  about  them  is  mounting.   These  letters serve  no useful or educational
  purpose, and are a waste of computer and network resources.

  For  reference  purposes,   a  "chain  letter"  is  any  mail message  that
  requests or implies  that the  receiver  should  re-broadcast  the  message
  to several  other  users.  The  phrase  "Send  a  copy of  this  letter  to
  20 other people  you know"  is an  example  of  the  type  of  wording  you
  will encounter  in a  chain  letter.  Quite  often,  you  will  receive the
  letter from someone you do NOT know.

  When you receive a  chain letter:  when  you find  that  you have  received
  a chain  letter,  it is  a  good  idea  to  forward  it  to  the operations
  manager  at  your  computer  center.  He  or  she  will  be  able  to  take
  appropriate  action,   such  as  contacting  the  computer  center  of  the
  person who originally sent the file.

  For  those who  might  think of  sending  a chain  letter:  such  abuse  of
  BITNET will  not be  tolerated by  most users  and most  computer  centers.
  Chain letters  are an  annoyance  to  the  user  community  at  large,  and
  their  broadcast and  rebroadcast results  only in  wasted  storage  space.
  If  you  receive  a   chain  letter,   purge  it  or  forward  it  to  your
  operations manager -- do NOT rebroadcast it.

  CSNEWS action:  if it can be  shown  that  a user  or group  of  users  has
  been  involved  in the  distribution  of  a chain  letter,  their access to
  CSNEWS  facilities   will  be    revoked   immediately  for  an  indefinite
  period.   If one of the CSNEWS  staff  receives,  directly  or  indirectly,
  a  copy  of  a  chain   letter,  he  or  she  may  immediately  notify  the
  operations staff  at  MAINE  and  at the  computer center  from  which  the
  letter originated.

1

                                                                      Page 18


   *************************************************************************
  * New Mailing Lists                                                       *
  ***************************************************************************

  AAI@ALMSA-1.ARPA

  Digest  for discussion of the  Automated AUTODIN Interface system.  The AAI
  system  is  a  series  of   programs  that  interface  a   data  processing
  installation  (DPI)  with  an AUTODIN  switching center.  This digest  will
  provide information to the user community and other personnel interested in
  the developments/enhancements and implementation thereof.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to AAIREQ@ALMSA-1.ARPA.

  Coordinator: Jo Ann M. Bohnenstiehl 
               Bob Savacool 


  ISO@NRTC.NORTHROP.COM

  Discussion  group  focusing  on the ISO protocol stack.  The list naturally
  has some overlap with  the ISODE list;  contributors  are urged to  use the
  appropriate list based on their topic of discussion.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to ISO-Request@NRTC.NORTHROP.COM.

  Coordinator: Marshall T. Rose 


  NeWS-makers@BRILLIG.UMD.EDU

  Mailing list for the  discussion  of NeWS:  the  Network/extensible  Window
  System.  NeWS, originally  called  SunDew, was  written primarily  by James
  Gosling, at Sun Microsystems, who is well  known for his Unix Emacs.   NeWS
  is an extensible  multitasking window  system environment, consisting  of a
  network  based  display  server  that   is  controlled  and  programmed  in
  PostScript, Adobe's page description  language.  NeWS was  designed to be a
  portable, device independent window system  development platform  that runs
  on a wide range of hardware, in a distributed heterogeneous environment.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to NeWS-makers-request@BRILLIG.UMD.EDU.

  Coordinator: don@BRILLIG.UMD.EDU

1

                                                                      Page 19


  TRANSPUTER@TCGOULD.TN.CORNELL.EDU

  The Transputer mailing list was created to enhance the  communication among
  those who are interested  in the Transputer  and Transputer  based systems.
  Submissions should be of  non-proprietary nature and be concerned with, but
  not limited to:

      Algorithms
      Current development efforts (hardware and software)
      INMOS and third party systems (Meiko, FPS, etc.)
      Interfaces
      Dedicated computational resources
      Occam and Non-Occam language development

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to transputer-request@TCGOULD.TN.CORNELL.EDU.

  Coordinator: Andy Pfiffer 


   *************************************************************************
  * The CSNET Information Server                                            *
  ***************************************************************************

  The CSNET Info-Server is an automatic  program that delivers information by
  electronic mail.   To order a document from the Info-Server, send a message
  to either 'INFO-SERVER@SH.CS.NET'or INFO-SERVER@CSNET-SH.ARPA.   You do not
  need a  subject field.    The text  of your  message must  be in  a special
  format, such as:

       REQUEST: INFO
        TOPIC: HELP
        TOPIC: ADR-3
       REQUEST: END

  This request asks for two documents  "HELP" and "ADR-3" from the collection
  "INFO".  Your message must have a "REQUEST" line,  and one or more "TOPIC:"
  lines  to specify  one or  more documents.    The line  "REQUEST:  END"  is
  optional; it tells the Info-server to ignore the rest of the message.

  To send documents to an address that  is different from the address in your
  From:  field,   please include  a Reply-to:   field in  the header  of your
  message.   Do NOT include a Reply-to: or Acknowledge-to:  field in the body
  of the message -- the Info-Server won't recognize them.

  For each request message, the Info-Server generates a receipt message which
  includes the list of  documents sent,  a report of errrors  in the request,
  and, if a Reply-to:  field is used, the address in the From:   field of the
  request message.

1

                                                                      Page 20


  The document you are now reading can be requested by:

      REQUEST: INFO
       TOPIC: HELP

  There are  currently four  REQUEST collections:   INFO,  RFC,   SOURCES and
  MOD.SOURCES.

  REQUEST: INFO         CSNET general information documents.

  REQUEST: RFC          Documents   in  the  "Request  for  Comments"  series
                        published  by  the  DDN  Network  Information  Center
                        (NIC).

  REQUEST: SOURCES      Files  of  program   sources   or  information  about
                        program sources from CSNET.

  REQUEST: MOD.SOURCES  An archive collection of public-domain programs  from
                        the "mod.sources" mailing list, distributed by USENET
                        netnews. These Unix source  file  have been  selected
                        and tested by the mod.sources  moderator.  The  first
                        two volumes  of the  total of  six  volumes  are  now
                        available.  Send for the topics HELP and INDEX.

  You may specify a limit, in lines or bytes, to the maximum size of document
  that you wish to have sent in a single message.  For example:

       LINE-LIMIT: 1000         or          BYTE-LIMIT: 75K

  The Info-Server will break the documents at exactly the specified number of
  lines,  or  at the  line preceeding  the specified  number of  bytes.   The
  minimum limit is 250 lines or 19000 bytes.  You may use the form "75000" or
  "75K" in either limit,  but NOT "75,000".   The limit affects only lines up
  to the next REQUEST: line.

  You  may combine  different  requests in  the same  message,   and use  any
  combination of upper-  and lower-case letters in your text.    You may also
  include or omit spaces and tabs, use any number of REQUEST and TOPIC lines,
  and omit "REQUEST: END".

                  REQUEST     : info
                    byte-limit: 22000
                    topic:      tbl-4a         (Byte-limit in effect)
                   TOPIC:       ml-2
                  Request :     rfc
                    TOPIC  :    rfc822         (Byte-limit not in effect)

1

                                                                      Page 21


  If you include "REQUEST: END", the Info-Server will ignore whatever follows
  in your message.  If you include "REQUEST: ATTENTION", the INFO SERVER will
  ignore whatever  follows and  deliver your  entire  message to  "CIC@CSNET-
  SH.ARPA".   (This  conforms to  MOSIS;  we  prefer that  you send  ordinary
  questions directly to "CIC@CSNET-SH.ARPA.)

  You are encouraged  to suggest additional documents you would  like to have
  available from the CSNET Info-Server.


   *************************************************************************
  * The United States Data Defense Network - Network Information Center     *
  ***************************************************************************

  This  is an  automated  service  provided  by the  DDN  Network Information
  Center.  It allows  access to  NIC documents  and  information via ordinary
  electronic mail.  This  is  especially  useful  for people  who do not have
  access to the  NIC via a  direct  Internet  link,  such  as  BITNET,  CSNET
  and UUCP sites.

  To use  the  mail  service,  send a  mail message  to SERVICE@SRI-NIC.ARPA.
  In the  SUBJECT  field,  request the  type  of service you wish followed by
  any  needed   arguments.   The  message  body  is  normally  ignored.   The
  information you request will be sent back to you as soon as possible.

  The following services are currently available:

  HELP           This message; a list of current services.
  RFC nnn        nnn is the RFC number or the word INDEX.
  IEN nnn        nnn is the IEN number or the word INDEX.
  NETINFO xxx    xxx is a file name or the word INDEX.
  HOST xxx       Returns information about host xxx.
  WHOIS xxx      Returns information about xxx from the WHOIS service.
                 Use "WHOIS HELP" for information on how to use WHOIS.

  Example SUBJECT lines:
  HELP
  RFC 822
  RFC INDEX
  NETINFO DOMAIN-TEMPLATE.TXT
  HOST SRI-NIC.ARPA
  WHOIS MKL

  Send comments or suggestions to SUGGESTIONS@SRI-NIC.ARPA.
  Send questions and bug reports to NIC@SRI-NIC.ARPA.

  BITNET/EARN/NETNORTH  users  should   check   to  see  if  the  information
  is  available   from  one   of   the   NETSERV  file  servers  (eg. NETSERV
  at BITNIC) first before requesting information  direct  from  the  DDN NIC.

1

                                                                      Page 22


  CSNET users should check  to see  if  the  information  is  available  from
  the  CSNET   information   server   (INFO-SERVER@SH.CS.NET)   first  before
  requesting information direct from the DDN NIC.


   *************************************************************************
  * The Color and Vision Network                                            *
  ***************************************************************************

  by Peter Kaiser                                             PKAISER@YORKVM1

  The Color and Vision Network is for scientists working in color  and vision
  research. At present the Network has three major activities.

  1. Members'  E-mail  addresses  are maintained and sent to all those in the
     Network.
  2. A key word list that associates scientists  and their  interests  within
     the areas of color and vision is maintained and distributed.
  3. Any person in the Network can have a  bulletin,  announcement, atc, sent
     all the other people in the Network.

  Scientists working in color and/or vision who wish  to join should  contact
  Peter Kaiser at:

                CVNET@YORKVM1 or
                CVNET%YORKVM1.BITNET@WISCVM.WISC.EDU

  They will receive the list of E-mail addresses  plus a  request to  provide
  key words  which represent  their interests and  experience in color and/or
  vision research.

  Scientists from Australia,  Canada,  Germany,  Japan,  Netherlands,  Sweden
  U.K.,  and the U.S.  are in  the  Network.  They  come  from  universities,
  research  institutes, national laboratories and private industry.  The list
  is growing daily.

                                Peter K. Kaiser
                                York University
                                4700 Keele St.
                                North York, Ontario, M3J 1P3
                                Canada


        * * *                                                     * * *
       * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
        * * *                                                     * * *

1                                                                     Page 23



   *************************************************************************
  * Feedback                                                                *
  ***************************************************************************

  Date:     Wed, 21-JAN-1987 21:12 PST
  From:     Don Hosek 
  To:       Christopher Condon 

  After seeing the recent  flood of letters in the January  NetMonth,  I just
  had to throw my  hat in  the ring.   Relay is  a valuable  but precariously
  balanced Bitnet resource.  I would suggest that those people who dashed off
  letters  to NetMonth  defending the  relay "clone"  read some  of the  back
  issues of NetMonth and  BitList and learn a little bit  about the old style
  chat machines and  the history of Relay.   In the days before  Relay,  chat
  machines were one of the biggest drains on network resources (and mostly so
  people could endlessly  say "hi.")  At an unnamed University  I once worked
  at,  for a user  services employee to be caught using  a chat machine meant
  termination. Period. Even now, relay use is not encouraged at this site (at
  least not until they get a Relay of their own, I'm told).

  The Relay clone while certainly an  excellent exercise in Rexx programming,
  was a danger to the status of Relay.  In appearance it resembled Relay, and
  it certainly was not good public relations for the supporters of Relay who,
  I  am certain,   are often  called upon  to  explain misuses  of Relay  and
  exceptional "loads" on the network from relay use. I might suggest that any
  users wishing to  learn to use IUCVTRAP  or WAKEUP or whatever  their heart
  desires stay away  from writing a program  that operates as a  chat machine
  unless it is *highly* restricted in the nodes that may use it,  i.e.,  only
  the  host  node and  possibly  those  linked  directly  to the  host  node.
  Certainly,  don't endanger  the status of legitamite  network services with
  "dangerous" programs.

  -Don Hosek

  ***************************************************************************

  Date:         Fri, 23 Jan 1987 10:33 SET
  From:         Eric Thomas 
  Subject:      Your relay clone
  To:           Niccolo Avico 
  cc:           Jeffrey R. Kell ,
                Christopher Condon 

  Nico,

  I have seen  the  discussion about the  RELAY clone you  wrote  in NetMonth
  and would like  comment on your  sayings (Chris, you can  include this mail
  in the next issue of NetMonth if you want).

1

                                                                      Page 24


  First,  we have   never accused you nor   ESC1040 of usurping the   name of
  RELAY or  similar  things  (just because  RELAY  is  a copyrighted  program
  does not mean  that we're going to   "scream like Khomeini" if  someone re-
  uses  the name  -- the main reason to  use  a different name is  to make it
  clear  to users that this is NOT the  same program and that  complaints/bug
  reports must  be  sent to  another userid).   Anyway you used   a different
  name, so there is  NO problem about copyright red tape and suchlike.

  The  main reason  why  I  would like  you not  to  distribute  your program
  to students any more is a purely TECHNICAL  reason: although it is probably
  a very interesting  REXX  experience, and  it  can  help a  new  REXX  user
  a  lot,   a centralized chat machine  like your CHATTER is a DANGER  to the
  network.  Please consider the following situation:    10 users from the USA
  are  signed up to your chat machine at ICNUCEVM.   Every time one of the 10
  users  sends out a message,  it gets  redistributed  to the 9 other  people
  on the channel. Each  of them is, say, about 9  nodes distant from ICNUCEVM
  on the average so you  get a  network load of about 80  messages.link (that
  is,  the same load as  if 80 messages  were being sent  on a single  link).
  If   the message  rate   is about  20  messages  per  minute  (that's   not
  much,  I've  seen  worse),   you  get   a  load  of  1600 messages.link per
  minute imposed on the  network.  This is with  just 10 users,  each sending
  but TWO messages per minute.   With 30 users sending 5 messages per minute,
  you  get   a  load    of  40,500   messages.link!!   This   means  complete
  saturation  of the   network  lines,   ie spool  files  can   no longer  be
  transferred.   This  does not  happen with  RELAY since  any  given message
  will   cross  the lines  only  once  and   will  get redistributed  by  the
  receiving  RELAY (hence the name).

  You   should  know   that   RELAY  has  been   tolerated   by   the  BITNET
  Executive Committee ONLY   provided that Joe  users be made  unable  to use
  it  during peak hours.  If  you start  allowing US students  to use a  chat
  machine  during work hours,  especially  a centralized chat machine  on the
  other side   of the ocean,  then   you are  definitely  going  against  the
  Executive Committee's  decision.

  Now about  ESC1040 and "Contact  sysops  if  you see bogus  relays!!":  you
  should  know that  the  majority  of  bogus relays  are  run ILLEGALLY   by
  students who have somehow obtained the exec. A chat machine  imposes a high
  load on the system it is running  on,   but  also on  OTHER systems  in the
  network.  The   local system contact is   responsible for this  before  the
  BITNET/EARN community and  must be able to   justify the load.   If a  chat
  machine is  causing the network  to stop transferring  files, HE  will  get
  the  blame.  I  therefore  find it  perfectly normal  that no  chat machine
  be allowed  without the  approval of  the system operator at the  site.  If
  the sysop  has given permission to run   the relay and receives a note from
  someone saying "There is a bogus relay   at your node",  he will just reply
  "No, it's an  officially approved machine" and the problem will be settled.

1

                                                                      Page 25


  You should  know  that  ESC1040 has  done  a lot  more than   just write  a
  chat  program.  From  what  I   heard he  has  been  abusing his   operator
  privileges to get accounts to run the   chat machines on.  From what I SAW,
  he  sent the authors of RELAY (including   me)  a  note saying  that he was
  the official  system contact person for his  node and that his chat machine
  was developed  in  collaboration  with a   the USSR  as part   of a  secret
  project,  etc.  This was an  insult to the official  representative of  his
  node   and it   is  probably   the reason   why  his  account was  removed,
  assuming it was (didn't hear about  it). His behaviour on his chat  machine
  was unacceptable,   I  heard  him criticizing openly  the  RELAY system and
  forcing RELAY users   to be signed on   his chat machine  even  though they
  wanted to get off.

  Last,  but  not  least,  let  me tell  you that  it is VERY   unpleasant to
  receive angry  complaints  from  network users/operators  about   a problem
  that is  not caused by  YOUR program, but  by someone else's.  I  have been
  in  this position several  times  and I can  only agree  with  Jeff when he
  says he would   like it made clear  and obvious that your  chat  machine is
  not his.  We have  no objection to you  chat program  provided  you respect
  the  network (ie limit  it's service area to  nodes which are very  near to
  your site,  which was not the  case with the machines ran  by ESC1040), and
  you   make it  clear  that this   is  a different  program  (which is  your
  interest as an author anyway).

  With kind regards,
                     Eric

  ***************************************************************************

  Date:         Fri, 23 Jan 87 08:46:51 EST
  From:         Jeffrey R Kell 
  Subject:      Re: Your relay clone
  To:           Eric Thomas ,
                Niccolo Avico 
  cc:           Christopher Condon 
  In-Reply-To:  Message of Fri, 23 Jan 1987 10:33 SET from 

  Just to summarize  briefly a lengthy note  I sent to Chris  (I thought this
  was all over, but didn't get a CC: of Niccolo's last letter)...

  The primary concerns of mine were,  as Eric mentioned,  (1)  confusion with
  the real relay,   leading to complaints to  me and (2)  misuse  of the EXEC
  which would lead to executive committee action and/or network trouble.

  The bottom line of all of this is:   the danger here is *who* has the EXEC,
  not *what*  the EXEC is.    Even though Relay  is somewhat accepted  by the
  network administration,  a copy of Relay can  be easily hacked to break the
  rules it  is designed  to enforce  (recall 'Psycho'  at Waterloo).    These
  "dark-side hackers" would misuse anything.    Perhaps they could,  in time,
  write their own  code;  but why give  them a head start.    And why provide
  "would-be-dark-side-hackers" who can't write one  of their own with working
  code ready to misuse.

1

                                                                      Page 26


  Date:         Tue, 27 Jan 87 16:58:27 SET
  From:         Hermann Schneider 
  Subject:      ESC1040 (RELAY clone)
  To:           Niccolo Avico 
  cc:           Christopher Condon 

  Hi,  I read the article in NetMonth about our RELAY clone.  I am the senior
  system  programer here  responsible  for data  communication  and our  EARN
  connection. To put things right:

  -ESC1040 was never removed from Bitnet

  -The RELAY clone was not the only  reason  to restrict  him to  use of  the
   network. The reasons are ipurely in the interest of the Agency.

  Therefore I  want to ask  Nico not to  start shouting against  something he
  doesn't  know.   Sentences  like 'acting  histerically  like  Komeini'  are
  misplaced here (it is you Nico who acts like this). There is also no reason
  to make the Americans responsible for what has happened.

  Stay cool and fair!
                       Hermann


   *************************************************************************
  * NetMonth Policies                                                       *
  ***************************************************************************

  If  you have questions or comments about BITNET or NetMonth  that you would
  like printed here,  mail your letter to BITLIB@YALEVMX.  Make sure that you
  specify in the "Subject:"  header or somewhere in the letter that it is for
  the NetMonth  letters  column. This  doesn't mean that your  letter will be
  printed, but it helps.  Your opinion counts!

  Article Submissions:  The  only requirements for NetMonth articles are that
  they be informative,  interesting, and  deal with  BITNET  services (or any
  other  good BITNET  related topics).  The  editor  will  inform  you of any
  changes to your writing and will submit them  for your  approval, deadlines
  permitting.  Send your articles to BITLIB@YALEVMX.

  ---------------------------------------------------------------------------

  FuzzyBytes Electronic Publishing                      "Because We're Here."